[우테코]프론트엔드 프리코스 1주차 후기

미션을 진행하면서 느낀 점 🧑‍💻

• [우테코]프론트엔드 프리코스 1주차 레포지토리

첫 번째 미션은 숫자야구게임을 구현하는 미션이었습니다. 처음 미션을 받았을 때 1주일이라는 시간 동안 충분히 구현이 가능할거라고 착각했습니다.

처음으로 일정한 코드 컨벤션과 커밋 컨벤션을 지키면서 프로그래밍을 진행하게 됐습니다. 컨벤션을 지키면서 프로그래밍을 하다 보니 기존에 함수 분리를 잘 안 하거나, depth에 신경 쓰지 않고 코딩하고 커밋 메세지를 대충 작성하는 등 기존에 가지고 있던 안 좋은 습관들을 깨달을 수 있었습니다.

코딩 컨벤션은 과제 레포지토리에 명시 된 depth제한과 함수나 메소드가 한가지 일만 하도록 최대한 작게 만들라는 점을 중점적으로 뒀고 추가적으로 레포지토리에서 제시한 Google Javascript Style Guide와 TOAST 코딩 컨벤션글을 참고했습니다. 두 문서와 Airbnb Javascript Style Guide 문서도 참고했습니다. 문서들 간에 서로 상충되는 부분이 존재해 특정 스타일 가이드를 무조건적으로 따르지는 않았습니다. 하지만 전체 코드가 일관성 있게 작성되도록 노력했습니다.

README 파일에 구현할 기능들을 미리 정리한 후 프로그래밍하는 경험도 이번이 처음이었습니다. 처음에 필요하다고 생각하고 적었던 기능들이 프로그래밍을 진행하면서 필요 없어지는 경우도 생기고 상세 명세들도 제 예상과 다른 기능이 필요할 때도 있어 README 파일을 자주 수정해야 했습니다. 하지만 구현해야 할 기능들을 미리 작성하고 진행하니 전체 플로우를 사전에 계획할 수 있었고 기능 단위 커밋 또한 가능해졌습니다! 또한 매번 프로그래밍을 시작하기 전 ‘아 뭐부터 하지’라는 멍 때리는 시간도 현저히 줄어들었습니다.

README 파일에 구현할 기능들을 작성하고 코딩 컨벤션, 커밋 컨벤션을 지켜가면서 프로그래밍을 하면서 장점들을 정말 많이 느꼈습니다. 앞으로 프로그래밍을 할 때 함께 해야할 좋은 습관들을 알게 돼서 정말 좋았습니다.

배운 점 👨‍🏫

• depth를 줄이자.

  • depth를 줄이면 자연스럽게 함수와 메소드가 분리 된다.
  • 코드를 리팩토링할 때 정말 편해진게 느껴졌습니다.
  • 또한 depth를 줄이기 위해 map(), reduce(), every()등 배열을 순회하는 순회 메소드들을 보다 다양하게 사용해 코드의 가독성을 높일 수 있었습니다.

• 함수와 메소드를 최대한 분리하자.

  • 위에 작성한 depth를 줄이다보니 코드를 리팩토링하기 편해진데에는 depth를 줄이면서 함수와 메소드가 분리 된 것도 한몫 했다고 생각합니다.
  • 하나의 함수가 하나의 기능만 하게 만들면 리팩토링할 때도 편하고 전체 로직을 따라가기도 좋았습니다.

• 코딩 컨벤션을 지키자.

  • 전체 코딩 컨벤션을 지키면서 코드를 작성하다보니 제가 제 코드를 볼 때도 일관성이 있어 좋았습니다.
  • 또한, 함수를 선언하거나 EventListener를 등록하는 것처럼 여러 방법으로 사용이 가능한 부분을 코딩 컨벤션을 가지고 일관성을 지키다보니 고민하는 시간이 적어졌습니다.

아쉬운 점 🤦‍♂️

• Javascript 메소드를 적재적소에 사용하지 못 했다.

  • 컴퓨터의 답과 유저의 인풋을 비교하는 부분에서 reduce()를 사용했는데 과제 제출 후 다른 분의 코드를 보니 비슷한 로직이지만 reduce()대신에 forEach()메소드를 사용해 보다 직관적이게 작성한 것을 보고 아차 싶었습니다.
  • Array.prototype.every()등 기존에 잘 사용하지 메소드들을 활용한건 고무적인 일이지만 메소드를 적재적소에 활용하기 위해 더 노력해야겠다고 생각했습니다.

• 인라인 함수를 분리하지 못 했다.

  • 유저의 인풋을 받는 부분에서 사용한 인라인 함수를 분리하기 위해 가장 많은 시간을 쏟았지만 결국 해결하지 못했습니다.
  • 클로저를 활용한 해결방법을 찾았지만 클로저를 스스로 잘 이해하지 못 했다고 생각한 점과 depth가 너무 깊어지는 점 때문에 해당 방법을 사용하지 못 했습니다.

• 함수 선언식 사용

  • ES6이후의 문법을 주로 사용해서 그동한 함수를 만들 때 함수 선언식보다는 함수 표현식을 많이 사용했습니다.
  • 과제에서 기본으로 주어지는 템플릿은 아래 두가지였습니다. export default function BaseballGame() {} export default class BaseballGame {}
  • 위의 두가지 중 하나를 선택해서 제출하게 되는데 저는 function을 선택해서 과제를 진행했습니다. 그러다보니 함수 표현식을 사용하게 되면 export와 export default를 혼용해서 사용해야 하고 전체 코드의 일관성을 해친다고 생각해서 전체 코드를 함수 선언식만을 사용해서 작성했습니다.
  • default로 주어지는 템플릿이 export default를 사용하는데 메인 템플릿을 제외하고 나머지 요소들을 함수 표현식을 사용해 export하는게 맞는건지에 대해서는 풀리지 않는 의문을 가지고 있습니다.

• 함수, 변수 네이밍

  • 함수를 최대한 분리하다보니 자연스럽게 함수의 개수가 많아졌고 그만큼 함수에 이름을 지어줄 일도 많아졌습니다.
  • 매번 긴 고민 끝에 함수와 변수의 이름을 지었지만 리팩토링할 때마다 이름을 계속 바꾸는 일을 반복했습니다.
  • 결국 모든 함수와 변수의 이름이 100% 마음에 들지는 않았지만 더 나은 대안을 찾지 못해 어쩔 수 없이 이름을 바꾸지 못한 채 과제를 제출했습니다.

앞으로 목표 🏃

1. 적절한 메소드 사용하기

   • 습관적으로 메소드를 사용하지 않고 다양한 메소드 찾아보고 적재적소에 적용하기.

2. 코딩 컨벤션 지키면서 프로그래밍 하기.

   • 전체 코드의 일관성을 유지하고 가독성을 높인다.

3. 커밋 컨벤션 지키면서 커밋하기.

   • 이후 어떤 시점에 어떤 항목을 변경했는지 한 눈에 파악할 수 있음.
   • 전체 커밋 메세지의 일관성을 통해 원하는 부분 빠르게 탐색 가능.

4. README에 기능 목록을 미리 작성한 후 프로그래밍 하기.

   • 전체 플로우를 미리 그려볼 수 있음.
   • 기능 별로 작성 단위를 쪼개서 프로그래밍 할 수 있음.

5. 네이밍에 더 신경쓰기

   • 단순 카멜케이스나 케밥케이스 같은 네이밍 컨벤션보다 확실한 컨벤션 정하기. (ex)행동 + 주체